Previous: Faces for TODO keywords, Up: TODO extensions [Contents][Index]
The structure of Org files (hierarchy and lists) makes it easy
to define TODO dependencies. Usually, a parent TODO task should
not be marked DONE until all subtasks (defined as children tasks)
are marked as DONE. And sometimes there is a logical sequence to
a number of (sub)tasks, so that one task cannot be acted upon
before all siblings above it are done. If you customize the
option org-enforce-todo-dependencies, Org will block
entries from changing state to DONE while they have children that
are not DONE. Furthermore, if an entry has a property
ORDERED, each of its children will be blocked until
all earlier siblings are marked DONE. Here is an example:
* TODO Blocked until (two) is done ** DONE one ** TODO two * Parent :PROPERTIES: :ORDERED: t :END: ** TODO a ** TODO b, needs to wait for (a) ** TODO c, needs to wait for (a) and (b)
org-toggle-ordered-property)Toggle the ORDERED property of the current
entry. A property is used for this behavior because this
should be local to the current entry, not inherited like a
tag. However, if you would like to track the value of
this property with a tag for better visibility, customize the
option org-track-ordered-property-with-tag.
Change TODO state, circumventing any state blocking.
If you set the option
org-agenda-dim-blocked-tasks, TODO entries that
cannot be closed because of such dependencies will be shown in a
dimmed font or even made invisible in agenda views (see Agenda Views).
You can also block changes of TODO states by looking at
checkboxes (see Checkboxes). If you set the
option org-enforce-todo-checkbox-dependencies, an
entry that has unchecked checkboxes will be blocked from
switching to DONE.
If you need more complex dependency structures, for example dependencies between entries in different trees or files, check out the contributed module org-depend.el.
Previous: Faces for TODO keywords, Up: TODO extensions [Contents][Index]